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REMARKS/ARGUMENTS 

Claims 12, 24, and 34 have been canceled 

Claim 13 has been re-written in independent form including all of the limitations of the 
cancelled base claim 12, there being no intervening claims. Claim 13 has also been amended to 
further distinguish Asawa by adding some language similar to the language found in claim 1. 
Claims 15, 16, 18, 20, 21, and 23 have been amended to depend on claim 13 instead of the 
cancelled claim 12. 

Claim 25 has been re-written in independent form including all of the limitations of the 
cancelled base claim 24, there being no intervening claims. Claim 25 has also been amended to 
further distinguish Asawa by adding some language similar to the language found in claim 1. 
Claims 27, 28, 30, 31, 32, and 33 have been amended to depend on claim 25 instead of the 
cancelled claim 24. 

Claim 35 has been re- written in independent form including all of the limitations of the 
cancelled base claim 34, there being no intervening claims. Claim 35 has also been amended to 
further distinguish Asawa by adding some language similar to the language found in claim 1. 
Claims 37, 38, 40, 41, and 42 have been amended to depend on claim 35 instead of the cancelled 
claim 34. 

Additional support for the amendments to claims 13, 25, and 35 is found in applicant's 
specification in FIGS. 5 and 6. The I/O request bunching main routine of FIG. 5 joins I/O 
requests in step 76 and initiates transmission of a joined request in a network transmission frame 
in step 79 when the joined size reaches 8 KB in step 78 to fill the network transmission frame. 
(See applicant's specification, paragraphs [00039] to [00042].) However, the I/O request 
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bunching periodic interrupt routine of FIG. 6 initiates transmission of one or more I/O requests in 
the joined request buffer in a partially filled network transmission frame upon expiration of the 
certain time interval "xl" in step 94. (See applicant's specification, paragraphs [00043] to 
00044].) Thus, transmission of each network transmission frame occurs upon the earlier of the 
filling of the network transmission frame in FIG. 5 (step 78 branching to step 79) or the 
expiration of the certain time interval in FIG. 6 (step 92 continuing to steps 93 and 94). 

On page 2 of the Official Action, claims 1 and 1 1 were rejected under 35 U.S.C. 103(a) 
as being unpatentable over Karpoff (U.S. 7,299,290) in view of Asawa et al. (U.S. 7,283,483). 
Applicant respectfully traverses. In short, the delay constraints of Asawa, where each delay 
constraint is associated with a packet, are not used to control whether or not the router of Asawa 
transmits a full network transmission frame or a partially filled network transmission frame, nor 
does the proposed combination of Karpoff and Asawa suggest use of a certain time interval to 
control the transmission of full or partially filled network transmission frames in the fashion as 
claimed by applicant. 

Karpoff is directed to a method and system for providing multimedia information on 
demand over wide area networks. (Karpoff, Title.) Streaming data content is delivered to a 
client device over a data communication network in response to a request for the data content 
from the client device. The client request is received by a server or a controller device that is 
typically located on a network switch device. If received by a server, the server sends a request 
to the controller device to control the transfer of the requested data to the client. The controller 
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device includes the processing capability required for retrieving the streaming data and 
delivering the streaming data directly to the client device without involving the server system. 
(Karpoff, Abstract.) 

Pages 2-3 of the Official Action cites Karpoff col. 12, lines 5-10. Karpoff col. 12, lines 
5-10 say: 

Towards this end, each computer attached to the Ethernet LAN, which 
includes both the clients 10) and server 12 (e.g., with reference to FIG. 7, 
transmits information in a way that accommodates a predefined packet size called 
a Maximum Transmission Unit (MTU), the value of which is 1,518 bytes for 
Ethernet. 

This passage of Karpoff, however, does not disclose details of how information is 
transmitted in such a way that accommodates a predefined packet size. Some further details are 
seen in Karpoff FIG. 6, which shows the Ethernet packet 70 to have a size of 1.518 GByte (i.e., 
1,5186 Megabytes). As described in Karpoff col. 12 lines 10-49-58: 

Referring back to FIG. 6, a typical data format for an audio and video 
payload is shown. In one embodiment, MPEG-II is used for transporting data 
payload 78, carrying one video and one audio channel as a video content. Each 
second of video data is compressed into 4 Megabits of digital data. The payload 
78 is comprised of sequential 4 Megabit packets 82. Each packet 82 is preferably 
streamed over the network 14 (e.g., FIG. 7) from a controller device 100 to a 
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client 10 initiating the request for audio and video data, the details of which will 
be described hereinafter. 

Thus, Karpoff discloses that a plurality of 4 Megabit packets 82 of MPEG-II streaming 
video are joined in an Ethernet packet for transmission over a LAN. 

Asawa discloses transmitting multiple packets in a frame. (Asawa, Title.) Transmitting 
packets in a frame includes receiving the packets. Delay constraints are established, where each 
delay constraint is associated with a packet. Frame departure times of the frames are predicted, 
where the frames include the packets. A packet departure time is determined for each packet in 
accordance with the frame departure time of the frame that includes the packet. An order of the 
packets is determined using the delay constraints and the packet departure times. The packets 
are placed in the order, and the frames are formed from the ordered packets. (Asawa, Abstract.) 

Page 3 of the Official Action cites Asawa for "delaying transmission of some of the data 
packets so that at least some of the frames each contain multiple data packets (col. 1, lines 13- 
18), and upon delaying packet transmission for the certain time interval, transmitting each data 
packet in at least one of the frames no later than a certain time interval after the respective time 
of said each data packet in the time sequence, and in order to ensure that said each data packet is 
transmitted in at least one of the frames no later than the certain time interval after the respective 
time of said each data packet in the time sequence (figure 4, references 110, 112, 114, and 116, 
col. 5, lines 14-22)." Asawa col. 5 lines 14-22 say: 
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Packet order manager 76 determines the packet order in accordance with 
the delay constraints and frame departure times at step 110. Packets may be 
ordered in accordance with the time budgets of the packets. Selector 78 selects the 
packets in the order determined by packet order manager 76 at step 112. The 
packets are sent in order to buffer 75 of multiplexer 48. Multiplexer 75 
multiplexes the packets to form frames at step 114. The frames are sent to 
transmitter 50, which transmits the frames at step 116. After transmitting the 
frames, the method terminates. 

Applicant agrees that Asawa does disclose delaying transmission of some of the data 
packets so that at least some of the frames each contain multiple data packets. For example, 
Asawa, col. 2 lines 33-37 say: "For voice traffic, however, the IP packets are small, so placing 
one packet in one Layer 2 frame may not be efficient due to large Layer 2 framing overhead. To 
address this efficiency problem, multiple packets may be encapsulated in one frame." Asawa 
col. 3 lines 1-7 further say: "For example, if a frame includes four packets such as a first, second, 
third, and fourth packet, the first packet must wait until second, third, and fourth packets are 
encapsulated before being transmitted. That is, if multiple packets are encapsulated in a frame, 
the frame is not transmitted until all packets have been encapsulated." 

Applicant, however, respectfully submits that neither Karpoff nor Asawa_discloses "upon 
delaying packet transmission for the certain time interval, transmitting each frame in a second set 
of the frames which are not filled with at least some of the data packets so that said each frame in 
the second set of the frames cannot contain an additional data packet in order to ensure that said 
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each data packet is transmitted in at least one of the frames no later than the certain time interval 
after the respective time of said each data packet in the time sequence." In other words, 
applicant's claim 1 defines that the transmission of a frame not entirely filled with data packets 
(i.e., a frame in the second set of frames) is a result of delaying transmission by the certain time 
interval but the transmission is not delayed by more than the certain time interval because each 
data packet is transmitted in at least one of the frames no later than the certain time interval after 
the respective time of said each data packet in the time sequence. Also, transmission of a frame 
entirely filled with data packets (i.e., a frame in the first set of frames) occurs upon filling the 
frame with data packets yet again packet transmission is not delayed by more than the certain 
time interval because each data packet is transmitted in at least one of the frames no later than 
the certain time interval after the respective time of said each data packet in the time sequence. 
Thus, the applicant's "certain time interval" governs whether or not a frame is transmitted before 
the frame is filled with data packets, and also governs when a partially filled frame is 
transmitted. 

Karpoff does not explicitly disclose transmission of a partially filled frame (i.e., a frame 
not filled so that it cannot contain an additional data packet) or suggest transmission of a frame 
not filled with data packets upon delaying packet transmission for a certain time interval yet each 
packet is transmitted no later than the certain time interval. Karpoff is directed to a video on 
demand system. In a video on demand system, it is desired to stream video data without delay in 
response to a client request. 
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Asawa does not explicitly disclose transmission of a partially filled frame (i.e., a frame 
not filled so that it cannot contain an additional data packet) upon delaying packet transmission 
for a certain time interval, in order to ensure that said each data packet is transmitted in at least 
one of the frames no later than the certain time interval after the respective time of said each data 
packet in the time sequence. Nor is it inherent in Asawa' s router that transmission of a partially 
filled frame occurs upon delaying packet transmission for a certain time interval, in order to 
ensure that said each data packet is transmitted in at least one of the frames no later than the 
certain time interval after the respective time of said each data packet in the time sequence. 

Asawa' s router includes input buffers 68 and an output buffer 75 in a multiplexer 48. 
(Asawa, FIG. 3.) Asawa's steps 114 and 116 form frames from packets received in the input 
buffers and these frames are transmitted in step 116. Asawa presumes that there is a frame 
transmission rate because Asawa's scheduler orders the packets in the frame based on the 
estimated time of transmission of the frame, which is estimated from the time of transmission of 
a previous frame. "For example, multiplexer 48 may notify scheduler 46 of when a frame has 
left multiplexer 48, or may inform scheduler 46 of a maximum transmission unit (MTU) of the 
channel." (Asawa, col. 4, lines 2-5.) 

In general, delay of data transmission through a router is undesirable. If one or more data 
packets happen to be received in the input buffers 68 of Asawa's router, this condition triggers 
the procedure of Asawa's FIG. 4 causing frame transmission. (See Asawa, col. 4, lines 59-62: 
"FIG. 4 is a flowchart illustrating one embodiment of a method for transmitting one or more 
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packets in a frame.") Therefore the frame transmission rate would increase up to a limit of the 
transmitter 50 or bandwidth of the transmission channel upon receipt of data packets in the input 
buffers 68 at a sufficient rate. There is nothing to suggest that the frame transmission rate from 
Asawa's router is dependent upon a delay of packet transmission for a certain time interval for 
partially filled frames. Nor does Asawa suggest that the frame transmission rate from Asawa's 
router is dependent upon delay constraints associated with data packets. 

Asawa recognizes but does not entirely solve a problem of packet transmission delay 
caused by encapsulating multiple packets in a frame. Instead of transmitting a partially filled 
frame upon delaying packet transmission for a certain time interval, Asawa orders the packets in 
a frame such that an optimal number of delay constraints are satisfied based on the predicted 
departure time of the frame. (Col. 3 lines 56-63; Col. 5 lines 7-13.) Asawa's scheduler orders 
the packets in the frame rather than deciding whether to transmit the frame before it is filled. 
Asawa's method may still violate the delay constraint of some packets having a "negative time 
budget." (Col. 4 lines 36-40.) Thus, an optimal number of delay constraints are satisfied, rather 
than satisfying all delay constraints. "For example, if the delay constraint of a packet is not 
satisfied, the packet may be moved before another packet, if the move does not violate the delay 
constraint of the other packet." (Col. 4, lines 53-56.) 

Because neither Karpoff nor Asawa suggests the use a "certain time interval" for 
governing whether or not a frame is transmitted before the frame is filled with data packets and 
also for governing when a partially filled frame is transmitted, it is not understood how the 
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subject matter of applicant's claim 1 is suggested by the proposed combination of Karpoff and 
Asawa. 

Nor is it understood why one would be motivated to modify Karpoff in view of Asawa. 
Karpoff appears to be entirely satisfactory for its intended purpose of streaming MPEG-II video 
on demand. The 4 Megabit packets 82 for each second of video data are rather large. In a video 
on demand system, it is desired to stream video data without delay in response to a client request. 
In contrast, Asawa is dealing with a different problem of transmitting and routing small IP 
packets for voice traffic in a telecommunications system. 

When determining whether a claim is obvious, an examiner must make "a searching 
comparison of the claimed invention - including all its limitations - with the teaching of the 
prior art." In re Ochiai . 71 F.3d 1565, 1572 (Fed. Cir. 1995) (emphasis added). Thus, 
"obviousness requires a suggestion of all limitations in a claim." CFMT, Inc. v. Yieldup Intern. 
Corp. . 349 F.3d 1333, 1342 (Fed. Cir. 2003) ( citing In re Royka . 490 F.2d 981, 985 (CCPA 
1974)). Moreover, as the Supreme Court stated, " there must be some articulated reasoning with 
some rational underpinning to support the legal conclusion of obviousness." KSR Int'l v. 
Teleflex Inc .. 127 S. Ct. 1727, 1741 (2007) (quoting In re Kahn, 441 F.3d 977, 988 (Fed. Cir. 
2006) (emphasis added)). A fact finder should be aware of the distortion caused by hindsight bias 
and must be cautious of arguments reliant upon ex post reasoning. See Id., 127 S. Ct. at 1742, citing 
Graham , 383 U. S. at 36 (warning against a "temptation to read into the prior art the teachings of the 
invention in issue" and instructing courts to "guard against slipping into the use of hindsight"). 
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With respect to applicant's claim 11, pages 3-4 of the Official Action cite Asawa (col. 5, 
lines 4-17) for disclosing "transmitting the frames over a data network, measuring loading on the 
data network, and dynamically adjusting the duration of the certain time interval based on the 
measured loading of the data network, the duration of the time interval being increased for 
increased loading on the data network." However, Asawa col. 5, lines 4-17 says: 

The delay constraint of a packet may be determined from the class assigned to 
the packet. Frame departure time estimator 74 predicts the frame departure times 
at step 108. The frame departure times are for the frames that would include the 
packets in the current order. The frame departure time of a frame that includes a 
packet is used as the packet departure time of the packet. A frame departure time 
for a frame may be predicted using information received from multiplexer 48 such 
as the departure time of a previous frame. 

In applicant's view, loading on the network is different from the frame departure times, 
and applicant's "certain time interval" is different from the Asawa' s delay constraints for the 
data packets. The applicant's "certain time interval" governs whether or not a full transmission 
frame or a partial transmission frame is transmitted, and governs when a partial transmission 
frame is transmitted. In contrast, Asawa determines a packet departure time from the estimated 
departure time of the frame that includes the packet, and determines an order of the packets in 
the frames using the delay constraints and the packet departure times. (Asawa, Abstract, and col. 
4 lines 26-36.) 
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On page 4 of the Official Action, claim 2 was rejected under 35 U.S. C. 103(a) as being 
unpatentable over Karpoff in view of Asawa and further in view of Smiroldo (U.S. 6,847,653). 
Applicant respectfully traverses. Page 5 of the Official Action cites Smiroldo for disclosing a 
timer interrupt routine in col. 9, lines 56-58. 

Smiroldo discloses a timer interrupt routine used in a wireless local area network for 
periodic transmission at 160 bytes into a 25 millisecond dwell which is split into two 12.5 
millisecond halves, one half dedicated to voice packets (a voice priority channel) and the other 
half dedicated to data frames (a data channel). See Smiroldo col. 1 lines 15-31 and col. 3 lines 
10-16. However, Smiroldo does not disclose or suggest the elements of the base claim 1 that are 
missing from Karpoff and Asawa. 

On page 6 of the Official Action, claims 3-4 were rejected under 35 U.S.C. 103(a) as 
being unpatentable over Karpoff in view of Asawa further in view of Eguchi (U.S. 6,895,483). 
Applicant respectfully traverses. Page 6 of the Official Action cites Eguchi for separately 
joining read I/O requests data packets together for transmission (col. 6, lines 5-9), and separately 
joining write I/O request data packets together for transmission (col. 6, lines 5-9), so that the I/O 
request data packets have an ordering in the frames that is different from the ordering of the I/O 
request data packets in the time sequence (figure 4, col. 7, lines 48-50). Eguchi col. 6 lines 5-9 
say: "The I/O network 140 is a transmission path for transferring an I/O command, read/write 
data, etc. between the storage subsystems 170 and the host system, and can be implemented by 
LAN, FDDI, Fibre Channel, SCSI, iSCSI, Infiniband or the like." Eguchi col. 7 lines 45-50 say: 
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"FIG. 4 is a diagram showing a data structure of the logical area use information 176. The logical 
area use information 176 is a table for totalizing the occupied time of each logical volume for 
each I/O type. The occupied time indicates the read/write time length consumed for the physical 
storage units 201." 

In applicant's view, Eguchi discloses different I/O types including sequential read, 
sequential write, random read, random write, etc., and these different I/O types would use 
different I/O request data packets. However, it is not seen where Eguchi discloses separately 
joining read I/O requests data packets together for transmission, and separately joining write I/O 
request data packets together for transmission, so that the I/O request data packets have an 
ordering in the frames that is different from the ordering of the I/O request data packets in the 
time sequence . Therefore, applicant's invention of claims 3-4 does not result from the proposed 
combination of Karpoff, Asawa, and Eguchi. 

On page 7 of the Official Action, claims 5-10 were rejected under 35 U.S.C. 103(a) as 
being unpatentable over Karpoff in view of Asawa further in view of Kodama (U.S. 7,460,473). 
Applicant respectfully traverses. With respect to claim 5, page 8 of the Official Action cites 
Kodama for disclosing on-line transaction processing applications in a host processor producing 
I/O request data packets, and a TCP/IP interface (col. 3, lines 57-58) in the host processor 
transmitting the frames over an IP network to network attached storage containing a database 
accessed by the on-line transaction processing applications (col. 16, line 1). 
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In applicant's view, Kodama discloses a TCP/IP-iSCSI networked storage server (106 in 
FIG. 1) serving application servers 104 (e.g., host computers, see col. 7 lines 30-33), and such 
application servers could include on-line transaction processing applications accessing a database 
in the network attached storage. Kodama, however, does not disclose or suggest the elements of 
the base claim 1 that are missing from Karpoff and Asawa. 

With respect to claim 6, page 8 of the Official Action cites Kodama for disclosing data 
packets are I/O replies from network attached storage, and the frames are transmitted to a host 
processor accessing the network attached storage (col. 20, lines 61-63). Kodama, however, does 
not disclose or suggest the elements of the base claim 1 that are missing from Karpoff and 
Asawa. 

With respect to claim 7, page 8 of the Official Action cites Kodama for disclosing the 
data packets are stored in a range of addresses of memory, a certain number of frames are 
preallocated in anther region of memory, and the data packets are joined by transfer of data 
packets from the range of addresses in memory to the preallocated frames in memory (col. 12, 
lines 12-18). However, Kodama col. 12, lines 12-18 say: "The Ethernet layer 170 serves as the 
media access control (MAC) protocol handler to transfer Ethernet frames across the physical link 
(e.g. physical network connection/layer). The format of the Ethernet frame is illustrated in FIG. 
5D. In one aspect, each frame comprises a MAC address that serves as a universally unique 
address that is pre-assigned for each Ethernet MAC device." In it not seen where Kodama 
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discloses the joining of data packets by transfer of data packets from a range of addresses in 
memory to preallocated frames in memory. 

With respect to claim 8, it is not seen where Kodama discloses that the certain number of 
preallocated frames is periodically updated. 

With respect to claim 9, it is not seen where Kodama discloses application threads 
loading data packets into the memory at the range of addresses in memory. The citation to page 
3, paragraph [0028] appears to be a citation to Madukkarumukumana et al. U.S. 2005/0030972 
from the first Official Action. 

With respect to claim 10, it is not seen where Kodama discloses TCP/IP threads 
accessing a pool of preallocated frames for transmission of the preallocated frames including the 
data packets over an IP network. Kodama col. 12, lines 1-5 relates to fragmentation of IP 
frames; for example, when the maximum transfer unit (MTU) of the device is smaller than the 
size of the IP frame it receives. 

On page 9 of the Official Action, claims 12, 24, and 34 were rejected under 35 U.S.C. 
103(a) as being unpatentable over Karpoff in view of Naik et al. (US 2004/0205206). In reply, 
in view of the disclosure of packet joining in Asawa, claims 12, 24, and 34 have been canceled. 
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On page 12 of the Official Action, claims 13-14, 25-26, and 35-36 were rejected under 35 
U.S.C. 103(a) as being unpatentable over Karpoff in view of Naik and further in view of Asawa. 
In reply, claims 12, 25, and 35 have been amended to include limitations similar to those found 
in clam 1 so that claims 12, 25, and 35 are patentable over the proposed combination of Karpoff 
and Asawa for the reasons discussed above with respect to applicant's claim 1. Page 9 of the 
Official Action cites Naik for disclosing I/O request data packets (page 1, paragraph [0006], lines 
3-4), and on-line transaction processing applications (page 1, paragraph [007], lines 4-7). 
However, Naik does not disclose joining data packets from different ones of the on-line 
transaction processing applications in the same network transmission frames to more completely 
fill the network transmission frames, nor does Naik disclose the limitations of claim 1 that are 
missing from Karpoff and Asawa. 

With respect to claims 14, 26, and 36, Asawa does not disclose dynamically adjusting a 
certain frame transmission delay in response to loading on the data network, so that the certain 
frame transmission delay is increased for increased loading on the data network, for the reasons 
discussed above with respect to applicant's claim 2. 

On page 14 of the Official Action, claims 15, 27, and 37 were rejected under 35 U.S.C. 
103(a) as being unpatentable over Karpoff in view of Naik and Smiroldo further in view of 
Asawa. In reply, claims 15, 27, and 37 have been amended to depend upon claims 12, 25, and 
35 as amended, respectively. Smiroldo does not disclose the limitations of claims 12, 25, and 35, 
as amended, which are missing from Karpoff, Naik, and Asawa. 
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On page 16 of the Official Action, claims 16-19, 28-30, and 38-40 were rejected under 35 
U.S.C. 103(a) as being unpatentable over Karpoff in view of Naik further in view of Eguchi et 
al. In reply, these claims have been amended to depend upon claims 12, 25, and 35 as amended, 
respectively. Eguchi does not disclose or suggest the limitations of claims 12, 25, and 35 that are 
missing from Karpoff, Naik, and Asawa. Moreover, as discussed above, applicant respectfully 
submits that Eguchi does not disclose separately joining read I/O request data packets together 
for transmission to the network block storage, and separately joining the write I/O request data 
packets together for transmission to the network block storage, and for moving some of the read 
I/O request data packets in front of some of the write I/O request data packets in some of the 
frames. 

With respect to claims 18, 30, and 40, pages 17-18 of the Official Action cites Eguchi 
col. 8, line 7 for "turning on and off the joining of the I/O request data packets." However, 
Eguchi col. 8 line 7 relates to a mode of a logical volume of storage. Eguchi col. 8 line 7 says: 
"The mode is divided into 'on-line', 'off-line', 'reserve', 'on-line reserve', etc." Packet joining 
is different from the on-line, off-line, reserve, or on-line reserve mode of a volume. It is not seen 
were Eguchi discloses turning on and off joining of I/O request data packets. 

With respect to claim 19, page 17 of the Official Action cites Eguchi col. 8 lines 9-10 for 
"the joining of the I/O request data packets is turned off during a bulk transfer of database data." 
However, Eguchi col. 8 lines 9-10 relates to an "offline" mode and a "reserve" mode of a logical 
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volume. Eguchi col. 8 lines 9-10 say: "The 'on-line' is the mode in which the particular logical 
volume is used by the host system, the 'off-line' the mode in which the logical volume cannot be 
used due to a fault or the like, the 'reserve' is the status reserved, and the 'on-line reserve' is the 
mode for reservation for data transmission from another storage subsystem 170." It is not 
understood how the disclosure of these possible modes of a logical volume would disclose or 
suggest that the joining of the I/O request data packets is turned off during a bulk transfer of 
database data. For example, there is no suggestion that joining of I/O request data packets 
should be turned off during data transmission to or from another storage subsystem. 

On page 18 of the Official Action, claims 20-23, 31-33, and 41-43 were rejected under 
35 U.S.C. 103(a) as being unpatentable over Karpoff in view of Naik further in view of Kodama. 
In reply, these claims have been amended to depend upon claims 12, 25, and 35 as amended, 
respectively. Moreover, as discussed above with respect to claims 7-10, applicant respectfully 
submits that Kodama does not disclose the joining of data packets by transfer of data packets 
from a range of addresses in memory to preallocated frames in memory as recited in applicant's 
claims 21 and 42, nor does Kodama disclose that the certain number of preallocated frames is 
periodically updated as recited in applicant's claims 22 and 43. 

In view of the above, it is respectfully submitted that the application is in condition for 
allowance. Reconsideration and early allowance are earnestly solicited. 
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Respectfully submitted, 



Richard C. Auchterlonie, Reg. No. 30,607 
NOVAK DRUCE & QUIGG, LLP 
1000 Louisiana, 53 rd Floor 
Houston, TX 77002 
713-571-3460 (Telephone) 
713-456-2836 (Telefax) 
Richard.Auchterlonie@novakdruce.com 
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